beautiful! 🚀

So this avoids having to hardcode context parameters – i.e. the app doesn't need to know the conditions in advance in order to match them to the right authentication method? That's pretty amazing!

One thing I'm wondering is – what resource is being queried here? Do we need to create a public resource that maps conditions to context parameters? Or is this a list that developers will create for their own domain?

So this avoids having to hardcode context parameters – i.e. the app doesn't need to know the conditions in advance in order to match them to the right authentication method? That's pretty amazing!

Indeed. This is the case where an application doesn't just use the same condition every time, but perhaps some permutations of a set of conditions, each with varying context parameters. In this way the dev can use logic to get the set of expected parameters and populate them based on their own logic.

They could have dynamic logic like the following:

if (requestedContextParmeters.has(":tokenId")) {
   // user subjected to condition 1 which uses ":tokenId" custom context parameter
   const value = ...
   conditionContext.addCustomContextParameters({":tokenId": value});
}
if (requestedContextParmeters.has(":otherParam")) {
   // user subjected to condition 2 which uses ":otherParam" custom context parameter
   const otherValue = ...
   conditionContext.addCustomContextParameters({":otherParam": otherValue});
}
if (requestedContextParmeters.has(":userAddress")) {
   // user subjected to condition with taco SIWE
   const authProvider = new EIP4361AuthProvider(...);
   conditionContext.addAuthProvider(":userAddress", auth provider);
}
if (requestedContextParmeters.has(":userAddressEIP4361")) {
   // user subjected to condition with single-sign on SIWE
   const authProvider = SingleSignOnEIP4361AuthProvider.fromExistingSiweInfo(...)
   conditionContext.addAuthProvider(":userAddressEIP4361", authProvider);
}
...

One thing I'm wondering is – what resource is being queried here?

Assuming I correctly understand the question, the ConditionContext looks at the underlying condition in the ThresholdMessageKit (encrypted data), and then returns all the context parameters in the underlying condition (requestedContextParameters property). It is then up to the app to populate the values appropriately. How they do that is up to them - we are not being prescriptive.

Do we need to create a public resource that maps conditions to context parameters? Or is this a list that developers will create for their own domain?

Interesting. To me, it's the latter. Devs can decide how they want to get/generate the values to use for conditions.
IMHO, on the decryption side, we should endeavour for apps not to have to deal with the underlying condition object(string) themselves. They can if they want to, of course, but they shouldn't really have to. It's part of the reason I made the ConditionContext object take a ThresholdMessageKit and not the condition object contained within the ThresholdMessageKit.

With something like a public mapping resource (condition string/type -> context parameters...?), it may be easy for simple conditions eg. BalanceOf, or OwnsNFT, but it's tough cover all cases with a mapping because our conditions are extensible, which is intentional for breadth of functionality. Devs can use whatever custom context parameters they want, and they can also use :userAddressExternalEIP4361 (single sign on SIWE) OR :userAddress (taco SIWE) if they like...it would be tough to cover all cases. Even with the mapping, they'll still need to know/determine what value to use for the context parameters - so they are kind of back to something like the 'if' statements above.